home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 15
/
Aminet 15 - Nov 1996.iso
/
Aminet
/
dev
/
gcc
/
ixemsdk.lha
/
man
/
cat3
/
time2posix.0
< prev
next >
Wrap
Text File
|
1996-09-02
|
4KB
|
133 lines
TIME2POSIX(3) TIME2POSIX(3)
NNAAMMEE
time2posix, posix2time - convert seconds since the Epoch
SSYYNNOOPPSSIISS
##iinncclluuddee <<ssyyss//ttyyppeess..hh>>
##iinncclluuddee <<ttiimmee..hh>>
ttiimmee__tt ttiimmee22ppoossiixx((tt))
ttiimmee__tt tt
ttiimmee__tt ppoossiixx22ttiimmee((tt))
ttiimmee__tt tt
cccc ...... --llzz
DDEESSCCRRIIPPTTIIOONN
IEEE Standard 1003.1 (POSIX) legislates that a time_t
value of 536457599 shall correspond to "Wed Dec 31
23:59:59 GMT 1986." This effectively implies that POSIX
time_t's cannot include leap seconds and, therefore, that
the system time must be adjusted as each leap occurs.
If the time package is configured with leap-second support
enabled, however, no such adjustment is needed and time_t
values continue to increase over leap events (as a true
`seconds since...' value). This means that these values
will differ from those required by POSIX by the net number
of leap seconds inserted since the Epoch.
Typically this is not a problem as the type time_t is
intended to be (mostly) opaque--time_t values should only
be obtained-from and passed-to functions such as _t_i_m_e_(_2_),
_l_o_c_a_l_t_i_m_e_(_3_), _m_k_t_i_m_e_(_3_), and _d_i_f_f_t_i_m_e_(_3_). However, POSIX
gives an arithmetic expression for directly computing a
time_t value from a given date/time, and the same rela-
tionship is assumed by some (usually older) applications.
Any programs creating/dissecting time_t's using such a
relationship will typically not handle intervals over leap
seconds correctly.
The _t_i_m_e_2_p_o_s_i_x and _p_o_s_i_x_2_t_i_m_e functions are provided to
address this time_t mismatch by converting between local
time_t values and their POSIX equivalents. This is done
by accounting for the number of time-base changes that
would have taken place on a POSIX system as leap seconds
were inserted or deleted. These converted values can then
be used in lieu of correcting the older applications, or
when communicating with POSIX-compliant systems.
_T_i_m_e_2_p_o_s_i_x is single-valued. That is, every local time_t
corresponds to a single POSIX time_t. _P_o_s_i_x_2_t_i_m_e is less
well-behaved: for a positive leap second hit the result is
not unique, and for a negative leap second hit the corre-
sponding POSIX time_t doesn't exist so an adjacent value
1
TIME2POSIX(3) TIME2POSIX(3)
is returned. Both of these are good indicators of the
inferiority of the POSIX representation.
The following table summarizes the relationship between a
time T and it's conversion to, and back from, the POSIX
representation over the leap second inserted at the end of
June, 1993.
DATE TIME T X=time2posix(T) posix2time(X)
93/06/30 23:59:59 A+0 B+0 A+0
93/06/30 23:59:60 A+1 B+1 A+1 or A+2
93/07/01 00:00:00 A+2 B+1 A+1 or A+2
93/07/01 00:00:01 A+3 B+2 A+3
A leap second deletion would look like...
DATE TIME T X=time2posix(T) posix2time(X)
??/06/30 23:59:58 A+0 B+0 A+0
??/07/01 00:00:00 A+1 B+2 A+1
??/07/01 00:00:01 A+2 B+3 A+2
[Note: posix2time(B+1) => A+0 or A+1]
If leap-second support is not enabled, local time_t's and
POSIX time_t's are equivalent, and both _t_i_m_e_2_p_o_s_i_x and
_p_o_s_i_x_2_t_i_m_e degenerate to the identity function.
SSEEEE AALLSSOO
difftime(3), localtime(3), mktime(3), time(2)
2